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METHOD OF GENERATING C CODE ON THE BASIS OF UML 

SPECIFICATIONS 



The subject matter of the present invention is a method for 
generating C code on the basis of UML specifications. 

There exist generators of C code on the basis of UML code, such 
5 as that from the company l-LOGIX, but the C language, not being an object 
code, it is not possible for « object » concepts such as heritage and 
polymorphism to be transcribed directly and automatically into C code. This 
impossibility limits the benefit of the use of UML modeling to produce C code. 
The known generators of 0 code produce only code « skeletons » or code 

10 reflecting a very limited use of UML concepts. 

The subject matter of the present invention is a method of 
generating C code on the basis of UML language specifications of a model, 
making it possible to automatically produce the entirety of the C code, both a 
static code (including the generation of classes and of relations) and a 

15 dynamic code (in particular for state machines), the code produced 
complying advantageously with the Do-178B level A specifications. The 
subject matter of the present invention is also a method which guarantees 
complete consistency between the C code generated and the specifications 
written in the UML model, which makes it possible to produce a G code 

20 generation report simultaneously with the generation of this code, as well as 
scripts for configuring, advantageously for the « Clearcase » tool from the 
company Rational-IBM. In the case of embedded systems, the 0 code thus 
produced for such systems will directly be embedded software. 

The method in accordance with the invention is characterized in 

25 that a detailed implementation model is produced in UML code, that the data 
of this model are structured to render them utilizable by the scripts generation 
tool "ModellnAction" (termed "MIA" and produced by the company 
Sodifrance), and that this tool is made to produce files in the C language, 
namely ".C" files, ".H" files, a generation report file, configuration 

30 management "batch" files and compilation project files. 

According to an advantageous characteristic of the invention, the 
0 code generated covers 100% of the UML specification of the software (the 
software generated is the embedded software) namely that the whole 
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generation spectrum is processed both statically (relations/classes) and 
dynamically (state machines). 

The present invention will be better understood on reading the 
detailed description of a mode of implementation, taken by way of nonlimiting 
5 example and illustrated by the appended drawing, in which: 

- Figure 1 is a diagram illustrating the main steps of the method of 
the invention, and 

- Figure 2 is a partial view of an exemplary generation report, 
corresponding to a generation report file that may be produced according to 

10 the method of the invention. 

In the example described hereinbelow, a UML language model is 
devised, in a conventional manner, with the aid of a tool (1) commonly used 
for this purpose, for example the « RHAPSODY » tool from the company I- 
LOGIX. The model thus created is exported (2) in the form of a file (3) in the 

15 XMI language. The production of the XMI file is done, for example, with the 
aid of an export toolkit such as the « XMI Toolkit » from the company I- 
LOGIX. The file 3 makes it possible to inject the UML data structure of said 
model into a file generation engine (4). This engine (4) is here the « Model In 
Action » tool (more simply dubbed « MIA ») from the company 

20 SODIFRANCE. It is associated with a scripts parametrization application (5), 
dubbed GEN_UML_C, produced by the Applicant. The engine (4) 
implements the application (5) to produce a series of five kinds of files, 
referenced (6) as a whole, representing the C code corresponding to the 
starting model. 

25 The series 6 of files comprises: « .C » files (7), « H » files (8), a code 

generation report file (9) (as demanded by the aforesaid. Do specifications), 
a « batch » file (10) in accordance with the « Clearcase » specifications and 
compilation project files (11). The files 7, 8 and 11 being produced in 
conventional manner, will not be described in greater detail. 

30 It is possible to manually modify the body of the procedures of the 

« .C » files generated. During subsequent generations, these modifications 
will not be overwritten but preserved and integrated within the new files 
generated. With MDE (Model Driven Engineering) in mind, in which the 
model and not the source files are the core of the development, it Is 

35 preferable to upload these manual modifications to the model. It is then 
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possible to integrate these modifications automatically into the model with the 
aid of the « roundtrip » tool called « ReverseC » (12). 

The report file (9) makes it possible to keep a log of the generation of 
the C code and to intercompare two versions of generation reports. In the 
5 present case, the report is an XML file comprising all the information 
corresponding to the UML model, the files and « packages » produced, the 
generation scenarios used, etc. An example of a screen shot of an extract of 
. such a report (« Generation report ») is represented in Figure 2. With each 
element of this report is associated one or more checksums (for example 32- 
10 bit CRCs) making it possible to perform the comparison between different 
versions and the detection of the modifications between these versions, for 
example between a new version of a generation and a reference version of a 
generation. 

On the basis of the comparisons thus made, various states are 
15 deduced which provide a « comparison state » of the file examined. The 
table below provides these comparison states. 



4 



Comparison 
states 


Description of the comparison state of the file 


Ngw 


Thp « npw » ^itr^tp rf^^prvpH fnr fll^^ th^t np^w with 

respect to the reference version. 


Unmodified 


AddIIgs when no modification has been made to a file with 

' xyj^l 1 WW VV 1 IV* 1 1 1 1 w 1 1 1 v/VI 1 1 1 wC4 LIVi/l 1 1 ICHO Li/ w wl 1 II IC1\J w L\J CI 1 1 1 w VV 1 LI 1 

respect to the reference file. 


Modified 


Applies when there have been modifications due solely to 
modifications of the UML model with resoect to the 

I 1 IV/VII 1 1 wdfclwl Iw ^^1 11 Iw ^^IVI^ 1 1 l%^VJ^7l VVmi 1 ^70l^wwL WJ Li iw 

reference file. 


Manually 
modified 


Applies in the case of manual modifications with respect to 
the reference version. 


Modified & 

manually 

modified 


Applies in the case of modifications of both types of a file 
with respect to the reference version. 


Removed 


Applies when a file no longer exists In a new version. An 
eliminated file is no longer taken into consideration in the 
subsequent generation reports. 



As illustrated in Figure 2, a generation report in accordance with the 
invention comprises in windows, as header, the following two items of 
5 information: 

Label of the version number of the reference report ("Reference 
report label"), 

- Label of the version number of the current report ("New report 
label"), originating from a previous version of the generation. 

10 Thereafter the body of the report comprises the following three 

columns: " item " (designation of the various constituent elements and access 
path in their storage unit), " Comparison status " (comparison state, in 
accordance with the table above) and " label " (indicating the version 
numbers in their category). The elements appearing in the first column are 

15 the following: 

- Designation of the UML model. Here, its state is " modified " and its 
version number is 2.0, 
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- Designation of the software collections (" packages In the 
example described here, these are Java and Clearcase collections. 
Here, they are unmodified and their version is 1 .0, 
Designation of the generation scenarios. In the example, these are 

5 Clearcase " batch " and Java generation scenarios. Here, they are 

unmodified and their version is 1 .0, 

- Designation of the files generated. In the example, these files are 
seven in number, all of version 2.0, the first is new, the statuses of 
the others being various, as Indicated in the second column. 

10 The bottom of the report comprises a window indicating the name 

of the scenario in progress (" batch Clearacase " in the present case), a 
" generate " button for launching a run of the generation of the scenario, and 
a first " files " window indicating the names of the Clearcase text files 
generated in this scenario, and a second " generated text " window 

15 displaying the text of these files. 

The Clearcase " batch " files are generated in such a way as to 
automatically update the Clearcase table comprising all the files of code 
generated, in accordance with the information appearing in the generation 
report. The updating of the Clearcase table is done in two phases, with the 

20 running of the following two PERL files: 

- "checkout.txt": this file prepares the update of the Clearcase table 
by verifying all the files modified. 

- "checkin.txt": this file represents the updated Clearcase table. 



